网络协议(二)--TCP传输控制协议(二)什么是三次握手、什么是四次握手

1、TCP/IP 五层协议模型
2、UDP初认识

今天来理解什么是三次握手，什么是四次挥手

图1 TCP连接管理

什么是三次握手

在网络数据传输中，传输层协议TCP(传输控制协议)是建立连接的可靠传输，TCP建立连接的过程，我们称为三次握手
第一次，客户端向服务器发送SYN同步报文段，请求建立连接
第二次，服务器客户端的连接请求进行确认收到，并向客户端发送SYN同步报文，向客户端建立连接
客户端收到服务器端的确认请求 + 建立连接请求后处于连接状态，客户端先处于建立连接状态
第三次，客户端向服务端发送确认请求
服务器收到客户端的确认也处于连接状态，服务端后处于建立连接状态

为什么建立连接时要进行三次握手？

我们可以分析一次握手肯定是不行的，这样服务器都不一定能收到连接请求

那么如果是两次握手呢?

如果是两次握手，连接过程应该是这样的，当服务器收到对端的连接请求时，就认为连接建立好了，进入ESTABLISHED状态。客户端在收到服务器发来的同步确认报文后，就认为连接建立好了，进入ESTABLISHED，在报文都能正常收到的情况下，两次握手是可以安全建立连接的。
但是存在这样的情况，假设第二次握手的报文丢失了，当前的状态是，服务器认为连接已经建立好了，可是客户端没有收到同步确认报文，认为连接还没有建立好，此时，服务器端的连接其实是无效连接，客户端因为没有收到确认，便会向服务器重传同步报文，同样，在服务器收到客户端的同步报文时，认为连接已经建立好了，同样糟糕的事情发生了，服务器给客户端发送的同步确认报文丢失了，或者是说有人恶意向服务器不断发送SYN同步报文（SYN洪水）。那么服务器端就会有大量的无效连接，服务器处理连接的数量是有限的，当有大量的无效连接建立后，服务器处理有效连接是能力就会受限，且建立连接会消耗大量是资源，至此有可能导致服务器崩溃。
这样看来两次握手是不可行的。

三次握手为什么是可行的呢？

在上面的两次握手的方案中，我们看到建立连接过程中，是服务器先处于连接建立好的状态，出现差错时，客户端没有连接建立成功，致使服务器可能有大量的无效连接，导致服务器安全问题。
那么在三次握手方案中，客户端收到服务器的同步确认报文后，就认为连接建立好了（先处于连接建立好的状态），而服务器是要收到客户端的确认报文后才认为连接建立好了。
那么也可能存在这样的问题，在最后一次握手时，服务器没有收到客户端的确认报文，此时的状态是，客户端处于建立连接状态，服务器处于未建立连接状态，此时客户端负责维护这次连接

1. 三次握手中，是主动先发起请求，主动方负责维护这次连接，那么会出现上面类似SYN洪水的问题吗？显然是不会的，自己发出SYN，最终无效连接还是建立在自己这方，客户端也不会这么无聊吧
2. 而当客户端尝试向服务器发送数据时，服务器看到的是，还没有建立连接的数据，服务器会响应一个带有RST标志位的报文，告知客户端你需要先建立连接，此时当客户端收到这个报文时，就会重新发起建立连接的请求。

总结下来就是，三次握手中，即使建立连接失败，对服务器是没有影响的，保证服务器的安全，而对客户端而言，也不过是多次建立连接而已。并且在经过验证，三次握手的成功率也是非常高的。

四次握手可行吗？

很明显，三次握手已经可以满足我们的需求了，也就没必要多一次而浪费资源了。
在两次握手和三次握手的方案中，我们发现要保证客户端先建立连接的话，能保证连接的安全建立。若是偶数次握手，或者是说让服务器先建立连接，就是不安全不可行的方案。所以四次 握手是不可行的。

什么是四次挥手

在网络数据传输中，传输层协议断开连接的过程我们称为四次挥手
第一次，A端像B端发送FIN结束报文段，准备关闭连接
第二次，B端确认A端的FIN，表示自己已经收到对方关闭连接的请求
在A发送完FIN后，中间这段时间，A端停止向B端发送数据，但是B端可以向A端发送数据，B端在准备关闭前需要将自己未处理完任务处理完。
第三次，B端向A端发送FIN结束报文段，准备关闭连接
第四次，A端确认B端的FIN，进入TIME_WAIT状态
此时A端进程已经退出，但连接还在
当B端收到A端的ACK确认之后断开连接，被动者先断开连接
当A端等待2 MSL之后，确认B端接收到ACK后再断开连接主动者后断开连接

• 发起断开连接请求的一端最后要进入有一个TIME_WAIT状态
• 发起连接请求的可以是客户端也可以是服务器端

为什么断开连接要四次?
不像建立连接的过程,服务器端在调用了accept()之后,剩下的都交给内核来处理,服务端就是处于等待建立连接的状态（从用户角度看就是服务器什么也不用做）,断开连接是AB两端在交流完成后，A端请求结束交流，很可能B端还需处理完剩余任务。B不能立即断开连接,就要先给出回复,表示自己已经收到消息了,然后将自己的数据处理完之后,可以断开连接的时候,再调用close()发出断开连接请求,在收到A端的确认回复之后,断开连接,这样看来每一步都不能少,但是有时候若服务器端没有什么要处理的数据,就看可以直接调用close()捎带上响应报文,此时就是3次

为什么先发起断开连接请求的一端最后要等待 2MSL？
MSL为一段报文从一端到另一端的最大时间，也称为报文的最大生存时间，我们假设在上面的四次挥手过程中最后A端在收到B端的FIN之后，就关闭连接，最后B端在收到A端对FIN的确认后也断开连接，这种情况是我们预期的，那就是A端先断开，然后B端再断开。

试想是否存在这样的情况，在A端已经关闭连接后，但是发给B端的ACK报文中途丢失，此时B端就会重发FIN结束报文段，但是A端已经关闭与这台服务器的连接，并且已经开始了一段新的连接，那么A端收到这个过期的FIN，误认为是关闭当前连接，给出错误处理。
也就是说A端等待 2MSL就 可以保证在B端没有收到A 到ACK时，B端重发的FIN，A端有机会接收。然后重新ACK确认等待2 MSL，需保证了最后的ACK 报文 B端成功收到。

对于上图的每个状态的补充：

1. CLOSED状态是一个假象的起始点，不是真是状态
2. 服务器是先被动打开的
3. 建立连接请求一定是客户端先发起的
4. 在建立连接的过程中，服务器端是由内核来完成的，而客户端应用层 connect 会一直伴随
5. 断开连接可以由客户端先断开，也可以由服务器端先断开
6. 对于上图中服务器端的 CLOSE_WAIT 状态的理解
   当服务器收到的请求数据返回为 0 时，表示对端关闭连接，先是由内核发送对对端数据请求的确认（ACK）,当服务器端将自己的数据都处理完成后，再调用 close(con_fd) 关闭连接，内核将其处理并发送结束报文段（FIN）。有时候若检测到程序中有大量的TIME_WAIT状态，很有可能是你的代码出现问题，在断开连接的时候没有及时的关闭文件操作。
7. 对于上图中客户端的 TIME_WAIT 状态的理解
   客户端在对服务器端的断开连接请求进行确认之后，进入TIME_WAIT状态，此时需要等待 2 MSL(报文最大生存时间，即报文从一端到另一端的时间)
   TCP协议规定，主动关闭连接的一方要处于TIME_WAIT状态
   为什么要等待2 MSL时间？
   a) 等待两个MSL,就可以保证两个传输方向上的尚未被接收的或者迟到的报文段都已经消失，倘若其中该进程中还有尚未接收的数据，而此刻立马启动服务器，服务器就会收到上个进程未处理的数据 ，收到的这个过期的报文有可能会携带一些关键信息，而影响服务器判断，这往往不是我们期待的。
   b) 等待两个MSL，就可以保证最后一个报文可靠到达，假设最后一个报文服务器没有收到，服务器就会重发 FIN 报文，因为此时客户端还没有真正断开连接，客户端会重发确认报文。